﻿
%% bare_conf.tex
%% V1.3
%% 2007/01/11
%% by Michael Shell
%% See:
%% http://www.michaelshell.org/
%% for current contact information.
%%
%% This is a skeleton file demonstrating the use of IEEEtran.cls
%% (requires IEEEtran.cls version 1.7 or later) with an IEEE conference paper.
%%
%% Support sites:
%% http://www.michaelshell.org/tex/ieeetran/
%% http://www.ctan.org/tex-archive/macros/latex/contrib/IEEEtran/
%% and
%% http://www.ieee.org/

%%*************************************************************************
%% Legal Notice:
%% This code is offered as-is without any warranty either expressed or
%% implied; without even the implied warranty of MERCHANTABILITY or
%% FITNESS FOR A PARTICULAR PURPOSE! 
%% User assumes all risk.
%% In no event shall IEEE or any contributor to this code be liable for
%% any damages or losses, including, but not limited to, incidental,
%% consequential, or any other damages, resulting from the use or misuse
%% of any information contained here.
%%
%% All comments are the opinions of their respective authors and are not
%% necessarily endorsed by the IEEE.
%%
%% This work is distributed under the LaTeX Project Public License (LPPL)
%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
%% distributed and modified. A copy of the LPPL, version 1.3, is included
%% in the base LaTeX documentation of all distributions of LaTeX released
%% 2003/12/01 or later.
%% Retain all contribution notices and credits.
%% ** Modified files should be clearly indicated as such, including  **
%% ** renaming them and changing author support contact information. **
%%
%% File list of work: IEEEtran.cls, IEEEtran_HOWTO.pdf, bare_adv.tex,
%%                    bare_conf.tex, bare_jrnl.tex, bare_jrnl_compsoc.tex
%%*************************************************************************

% *** Authors should verify (and, if needed, correct) their LaTeX system  ***
% *** with the testflow diagnostic prior to trusting their LaTeX platform ***
% *** with production work. IEEE's font choices can trigger bugs that do  ***
% *** not appear when using other class files.                            ***
% The testflow support page is at:
% http://www.michaelshell.org/tex/testflow/



% Note that the a4paper option is mainly intended so that authors in
% countries using A4 can easily print to A4 and see how their papers will
% look in print - the typesetting of the document will not typically be
% affected with changes in paper size (but the bottom and side margins will).
% Use the testflow package mentioned above to verify correct handling of
% both paper sizes by the user's LaTeX system.
%
% Also note that the "draftcls" or "draftclsnofoot", not "draft", option
% should be used if it is desired that the figures are to be displayed in
% draft mode.
%
\documentclass[conference]{IEEEtran}
% Add the compsoc option for Computer Society conferences.
%
% If IEEEtran.cls has not been installed into the LaTeX system files,
% manually specify the path to it like:
% \documentclass[conference]{../sty/IEEEtran}




% Some very useful LaTeX packages include:
% (uncomment the ones you want to load)


% *** MISC UTILITY PACKAGES ***
%
\usepackage{ifpdf}
% Heiko Oberdiek's ifpdf.sty is very useful if you need conditional
% compilation based on whether the output is pdf or dvi.
% usage:
% \ifpdf
%   % pdf code
% \else
%   % dvi code
% \fi
% The latest version of ifpdf.sty can be obtained from:
% http://www.ctan.org/tex-archive/macros/latex/contrib/oberdiek/
% Also, note that IEEEtran.cls V1.7 and later provides a builtin
% \ifCLASSINFOpdf conditional that works the same way.
% When switching from latex to pdflatex and vice-versa, the compiler may
% have to be run twice to clear warning/error messages.






% *** CITATION PACKAGES ***
%
\usepackage{cite}
% cite.sty was written by Donald Arseneau
% V1.6 and later of IEEEtran pre-defines the format of the cite.sty package
% \cite{} output to follow that of IEEE. Loading the cite package will
% result in citation numbers being automatically sorted and properly
% "compressed/ranged". e.g., [1], [9], [2], [7], [5], [6] without using
% cite.sty will become [1], [2], [5]--[7], [9] using cite.sty. cite.sty's
% \cite will automatically add leading space, if needed. Use cite.sty's
% noadjust option (cite.sty V3.8 and later) if you want to turn this off.
% cite.sty is already installed on most LaTeX systems. Be sure and use
% version 4.0 (2003-05-27) and later if using hyperref.sty. cite.sty does
% not currently provide for hyperlinked citations.
% The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/cite/
% The documentation is contained in the cite.sty file itself.






% *** GRAPHICS RELATED PACKAGES ***
%
\ifCLASSINFOpdf
  \usepackage[pdftex]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../pdf/}{../jpeg/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.pdf,.jpeg,.png}
\else
  % or other class option (dvipsone, dvipdf, if not using dvips). graphicx
  % will default to the driver specified in the system graphics.cfg if no
  % driver is specified.
  % \usepackage[dvips]{graphicx}
  % declare the path(s) where your graphic files are
  % \graphicspath{{../eps/}}
  % and their extensions so you won't have to specify these with
  % every instance of \includegraphics
  % \DeclareGraphicsExtensions{.eps}
\fi
% graphicx was written by David Carlisle and Sebastian Rahtz. It is
% required if you want graphics, photos, etc. graphicx.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at: 
% http://www.ctan.org/tex-archive/macros/latex/required/graphics/
% Another good source of documentation is "Using Imported Graphics in
% LaTeX2e" by Keith Reckdahl which can be found as epslatex.ps or
% epslatex.pdf at: http://www.ctan.org/tex-archive/info/
%
% latex, and pdflatex in dvi mode, support graphics in encapsulated
% postscript (.eps) format. pdflatex in pdf mode supports graphics
% in .pdf, .jpeg, .png and .mps (metapost) formats. Users should ensure
% that all non-photo figures use a vector format (.eps, .pdf, .mps) and
% not a bitmapped formats (.jpeg, .png). IEEE frowns on bitmapped formats
% which can result in "jaggedy"/blurry rendering of lines and letters as
% well as large increases in file sizes.
%
% You can find documentation about the pdfTeX application at:
% http://www.tug.org/applications/pdftex





% *** MATH PACKAGES ***
%
%\usepackage[cmex10]{amsmath}
% A popular package from the American Mathematical Society that provides
% many useful and powerful commands for dealing with mathematics. If using
% it, be sure to load this package with the cmex10 option to ensure that
% only type 1 fonts will utilized at all point sizes. Without this option,
% it is possible that some math symbols, particularly those within
% footnotes, will be rendered in bitmap form which will result in a
% document that can not be IEEE Xplore compliant!
%
% Also, note that the amsmath package sets \interdisplaylinepenalty to 10000
% thus preventing page breaks from occurring within multiline equations. Use:
%\interdisplaylinepenalty=2500
% after loading amsmath to restore such page breaks as IEEEtran.cls normally
% does. amsmath.sty is already installed on most LaTeX systems. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/amslatex/math/





% *** SPECIALIZED LIST PACKAGES ***
%
%\usepackage{algorithmic}
% algorithmic.sty was written by Peter Williams and Rogerio Brito.
% This package provides an algorithmic environment fo describing algorithms.
% You can use the algorithmic environment in-text or within a figure
% environment to provide for a floating algorithm. Do NOT use the algorithm
% floating environment provided by algorithm.sty (by the same authors) or
% algorithm2e.sty (by Christophe Fiorio) as IEEE does not use dedicated
% algorithm float types and packages that provide these will not provide
% correct IEEE style captions. The latest version and documentation of
% algorithmic.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithms/
% There is also a support site at:
% http://algorithms.berlios.de/index.html
% Also of interest may be the (relatively newer and more customizable)
% algorithmicx.sty package by Szasz Janos:
% http://www.ctan.org/tex-archive/macros/latex/contrib/algorithmicx/




% *** ALIGNMENT PACKAGES ***
%
%\usepackage{array}
% Frank Mittelbach's and David Carlisle's array.sty patches and improves
% the standard LaTeX2e array and tabular environments to provide better
% appearance and additional user controls. As the default LaTeX2e table
% generation code is lacking to the point of almost being broken with
% respect to the quality of the end results, all users are strongly
% advised to use an enhanced (at the very least that provided by array.sty)
% set of table tools. array.sty is already installed on most systems. The
% latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/required/tools/


%\usepackage{mdwmath}
%\usepackage{mdwtab}
% Also highly recommended is Mark Wooding's extremely powerful MDW tools,
% especially mdwmath.sty and mdwtab.sty which are used to format equations
% and tables, respectively. The MDWtools set is already installed on most
% LaTeX systems. The lastest version and documentation is available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/mdwtools/


% IEEEtran contains the IEEEeqnarray family of commands that can be used to
% generate multiline equations as well as matrices, tables, etc., of high
% quality.


%\usepackage{eqparbox}
% Also of notable interest is Scott Pakin's eqparbox package for creating
% (automatically sized) equal width boxes - aka "natural width parboxes".
% Available at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/eqparbox/





% *** SUBFIGURE PACKAGES ***
%\usepackage[tight,footnotesize]{subfigure}
% subfigure.sty was written by Steven Douglas Cochran. This package makes it
% easy to put subfigures in your figures. e.g., "Figure 1a and 1b". For IEEE
% work, it is a good idea to load it with the tight package option to reduce
% the amount of white space around the subfigures. subfigure.sty is already
% installed on most LaTeX systems. The latest version and documentation can
% be obtained at:
% http://www.ctan.org/tex-archive/obsolete/macros/latex/contrib/subfigure/
% subfigure.sty has been superceeded by subfig.sty.



%\usepackage[caption=false]{caption}
%\usepackage[font=footnotesize]{subfig}
% subfig.sty, also written by Steven Douglas Cochran, is the modern
% replacement for subfigure.sty. However, subfig.sty requires and
% automatically loads Axel Sommerfeldt's caption.sty which will override
% IEEEtran.cls handling of captions and this will result in nonIEEE style
% figure/table captions. To prevent this problem, be sure and preload
% caption.sty with its "caption=false" package option. This is will preserve
% IEEEtran.cls handing of captions. Version 1.3 (2005/06/28) and later 
% (recommended due to many improvements over 1.2) of subfig.sty supports
% the caption=false option directly:
%\usepackage[caption=false,font=footnotesize]{subfig}
%
% The latest version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/subfig/
% The latest version and documentation of caption.sty can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/caption/




% *** FLOAT PACKAGES ***
%
%\usepackage{fixltx2e}
% fixltx2e, the successor to the earlier fix2col.sty, was written by
% Frank Mittelbach and David Carlisle. This package corrects a few problems
% in the LaTeX2e kernel, the most notable of which is that in current
% LaTeX2e releases, the ordering of single and double column floats is not
% guaranteed to be preserved. Thus, an unpatched LaTeX2e can allow a
% single column figure to be placed prior to an earlier double column
% figure. The latest version and documentation can be found at:
% http://www.ctan.org/tex-archive/macros/latex/base/



%\usepackage{stfloats}
% stfloats.sty was written by Sigitas Tolusis. This package gives LaTeX2e
% the ability to do double column floats at the bottom of the page as well
% as the top. (e.g., "\begin{figure*}[!b]" is not normally possible in
% LaTeX2e). It also provides a command:
%\fnbelowfloat
% to enable the placement of footnotes below bottom floats (the standard
% LaTeX2e kernel puts them above bottom floats). This is an invasive package
% which rewrites many portions of the LaTeX2e float routines. It may not work
% with other packages that modify the LaTeX2e float routines. The latest
% version and documentation can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/sttools/
% Documentation is contained in the stfloats.sty comments as well as in the
% presfull.pdf file. Do not use the stfloats baselinefloat ability as IEEE
% does not allow \baselineskip to stretch. Authors submitting work to the
% IEEE should note that IEEE rarely uses double column equations and
% that authors should try to avoid such use. Do not be tempted to use the
% cuted.sty or midfloat.sty packages (also by Sigitas Tolusis) as IEEE does
% not format its papers in such ways.





% *** PDF, URL AND HYPERLINK PACKAGES ***
%
\usepackage{url}
% url.sty was written by Donald Arseneau. It provides better support for
% handling and breaking URLs. url.sty is already installed on most LaTeX
% systems. The latest version can be obtained at:
% http://www.ctan.org/tex-archive/macros/latex/contrib/misc/
% Read the url.sty source comments for usage information. Basically,
% \url{my_url_here}.





% *** Do not adjust lengths that control margins, column widths, etc. ***
% *** Do not use packages that alter fonts (such as pslatex).         ***
% There should be no need to do such things with IEEEtran.cls V1.6 and later.
% (Unless specifically asked to do so by the journal or conference you plan
% to submit to, of course. )


% correct bad hyphenation here
%\hyphenation{op-tical net-works semi-conduc-tor}

\begin{document}

%
% paper title
% can use linebreaks \\ within to get better formatting as desired
\title{Infrastructure for Intrusion Detection on Xen Virtualization}


% author names and affiliations
% use a multiple column layout for up to three different
% affiliations
\author{\IEEEauthorblockN{Nilushan Silva}
\IEEEauthorblockA{University of Colombo \\ School of Computing\\
Sri lanka\\
Email: nilushanucsc@gmail.com}
\and
\IEEEauthorblockN{Dr. Chamath Keppetiyagama}
\IEEEauthorblockA{University of Colombo \\ School of Computing\\
Sri lanka\\
Email: chamath@ucsc.cmb.ac.lk}
}

% conference papers do not typically use \thanks and this command
% is locked out in conference mode. If really needed, such as for
% the acknowledgment of grants, issue a \IEEEoverridecommandlockouts
% after \documentclass

% for over three affiliations, or if they all won't fit within the width
% of the page, use this alternative format:
% 
%\author{\IEEEauthorblockN{Michael Shell\IEEEauthorrefmark{1},
%Homer Simpson\IEEEauthorrefmark{2},
%James Kirk\IEEEauthorrefmark{3}, 
%Montgomery Scott\IEEEauthorrefmark{3} and
%Eldon Tyrell\IEEEauthorrefmark{4}}
%\IEEEauthorblockA{\IEEEauthorrefmark{1}School of Electrical and Computer Engineering\\
%Georgia Institute of Technology,
%Atlanta, Georgia 30332--0250\\ Email: see http://www.michaelshell.org/contact.html}
%\IEEEauthorblockA{\IEEEauthorrefmark{2}Twentieth Century Fox, Springfield, USA\\
%Email: homer@thesimpsons.com}
%\IEEEauthorblockA{\IEEEauthorrefmark{3}Starfleet Academy, San Francisco, California 96678-2391\\
%Telephone: (800) 555--1212, Fax: (888) 555--1212}
%\IEEEauthorblockA{\IEEEauthorrefmark{4}Tyrell Inc., 123 Replicant Street, Los Angeles, California 90210--4321}}




% use for special paper notices
%\IEEEspecialpapernotice{(Invited Paper)}




% make the title area
\maketitle


\begin{abstract}
%\boldmath

Security violations to Operating systems are increasing every day. Tools and architectures that detect security violations have a flaw in design that prevents proper detection of kernel level attack. Virtualization provides a new design for reliable security exploit detection. Exploit detection of one virtual host from another opens up a few more challenges to be handled. Accessing low level memory page tables for address translation and semantic regeneration of kernel objects should be handled before a detection system can be run. This paper discusses about the problem in current detection systems, the new solution using Xen virtualization, the kernel sections that can be detected and the challenges of using Xen for intrusion detection. 
The paper discusses how the integrity detector to detect the integrity of system call table  is implemented. The implementation detects all changes made to the system call table with no performance impact. 



\end{abstract}
% IEEEtran.cls defaults to using nonbold math in the Abstract.
% This preserves the distinction between vectors and scalars. However,
% if the conference you are submitting to favors bold math in the abstract,
% then you can use LaTeX's standard command \boldmath at the very start
% of the abstract to achieve this. Many IEEE journals/conferences frown on
% math in the abstract anyway.

% no keywords




% For peer review papers, you can put extra information on the cover
% page as needed:
% \ifCLASSOPTIONpeerreview
% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
% \fi
%
% For peerreview papers, this IEEEtran command inserts a page break and
% creates the second title. It will be ignored for other modes.
\IEEEpeerreviewmaketitle



\section{Introduction}
% no \IEEEPARstart

The ideal secure system requires that the system is running on top of a secure base. The base of any system is the operating system. Unfortunately operating systems are programs with huge code bases which contain many bugs. These buggy programs can be exploited to break the security of systems. 

When an application is compromised by an attacker, he can eventually compromise the kernel and when the kernel is compromised he can get control of the whole system. To avoid access of a computer system by an unauthorized person, proper detection of the attacks have to be done. Programs which detect these intrusive activities are called Intrusion Detection Systems (IDS). Once detection has been done, the necessary decision and action needed to take to restore proper trusted state of the system can be done thereafter. Therefore the most important requirement in making a system trustable is to have a reliable detection system which can detect any attack flawlessly.

The existing IDS reside on the same kernel as the monitored host. Once a attack has occurred, the IDS or the monitored host OS can be modified or attacked by the attacker to hide its intrusive activities, making the IDS unreliable. The ideal intrusion detection system is a system which can scan the vulnerable host thoroughly while being protected against a attack happening on the host. This requires good visibility and proper isolation from the vulnerable host to the detection system. The above two requirements are conflicting requirements in the context of a normal computer architecture. The architecture which allows both good visibility and proper isolation between monitored host and the IDS is the use of virtualization.

The vulnerable host and the IDS will run on two different virtual machines. The fact that both these VMs run on top of the same physical machine can provide the visibility into the vulnerable host's state. Virtualization provides a great deal of isolation between VMs running on top of the hypervisor. These properties provided by virtualization can be used to implement a reliable IDS. 

There are several ways in which intrusion detection is carried out, such as network packet detection, file system integrity detection and memory integrity detection. File system integrity checking on virtualized hosts is considered to be possible without too much difficulty as the semantics of the file system are available there itself and can be accessed with semantics from other hosts as well. Recreation of memory semantic is harder on the other hand because meta data about semantics are not easy to access. Therefore memory integrity detecting which needs memory semantics regeneration is much more challenging. The aim of this paper is to discuss issues about memory integrity detection since it is a challenging research area. Therefore we will mostly discuss only about memory detection and memory semantics regeneration, which are needed for memory integrity checking.

Memory introspection is the main issue discussed in this paper. Memory introspection is the process of viewing the memory of one virtual machine from a different virtual machine. Even though from the surface this seems rather simple, it is a very tedious task. When the detection system runs on the detected host itself, the detector can have access to the state of the system together with the semantics of its operating system. But when the detector is run on a different VM, even though the VM can be provided with the visibility, what the monitor is provided is raw data in bits which does not contain any semantics. For detection to be done properly the semantics have to be regenerated from the raw memory. 

Memory management used different layers of memory. Xen uses three layers of memory for addressing. The initial step when dealing with memory is the translation of addresses. Address translation will be done by traversing the page tables of the virtual hosts. After the addresses have been translated, memory of the vulnerable host will be mapped on to the memory of the monitoring VM's memory space. Next the semantic less raw memory will have to be provided with the semantics to do any useful monitoring. Once the semantics of the mapped memory have been provided the ability to scan the memory of the other VM can be provided.




%\hfill mds
%\hfill January 11, 2007

\section{Background}

The issue that is addressed in the paper is on the problem that exists on currently available intrusion detection systems. The need of these detection systems arise due to the malicious software that compromise computer systems. The proposed solution is made of virtualization technology. The above areas which are of importance to understand the problem and the solution will be introduced in this section.




\subsection{Intrusion Detection Systems}

Intrusion Detection System(IDS) is a software application that detects unwanted manipulations by attackers to computer systems. IDS can detect when an attacker has successfully compromised a system by exploiting vulnerability in the system. The IDS could then report the incident to security administrators and log information that could be used by the incident handlers. IDSs are divided into two types which are network based IDS (NIDS) and host based IDS (HIDS). 

NIDS identifies intrusions by examining network traffic and monitors traffic of multiple hosts. NIDS operate by monitoring all incoming packets to finding suspicious patterns and also inspects outgoing traffic for valuable information communicating on the network. NIDS have higher attack resistance but does not have the ability to detect the activities happening on the monitored hosts. 
HIDS monitors the state and the events occurring within that host for suspicious activity. Some of the things analyzed are system calls, application logs, file-system modifications (binaries, password files,  databases).

HIDS have the ability to monitor the activities happening on the host(Good Visibility) but it is easier to be attacked. If the Host is compromised the HIDS too is bound to be attacked and when it is under attack it won’t be able to detect intrusions reliably.

There are a few types of HIDS based on the detection mechanism they use \cite{hids}. File system  monitors check the integrity of files and directories. Logfile analyzers analyze logfiles for patterns indicating suspicious activity. Connection analyzers monitor network connection attempts to and from a host. Kernel based IDSs detect malicious activity on a kernel level.


IDS can be defeated by either \emph{Evading} or \emph{Attacking}. Evading an IDS is done by disguising the malicious activity so that the IDS fails to recognize it. Attacking a IDS is by tampering with the IDS in a way that it will not be able to detect or report malicious activities. The architecture of a computer is such that a HIDS should reside on the same kernel as the vulnerable kernel resides on. This flaw inherent by the architecture is the problem making the IDS not fully reliable, which is the primary problem that is tried to be resolved in the new detection system.


\subsection{Malicious Software}



\label{sec:IntrusiveActivities }
Compromising software can be done in many different ways. Τhere are various different kinds of malicious software such as viruses, trojans, malware and rootkits. Here Rootkits will be considered as the type of attach handled by the system.
 
\subsubsection {Rootkits}
Rootkits are malicious software that allow the attacker to keep controlling the system while hiding its presence.

Once the attackers have gained access to a System, they install the rootkit into the kernel and then they hide their activities from being detected. For this purpose attackers inject rootkits which replace or modify the System Binaries, replace system libraries with trojanised versions, modify kernel data structures to provide stealth \cite{rootkits}.  
 
\textbf{Binary or User level rootkits} replace binaries of system utilities so that the malicious processes, files, ports open can be hidden so that the rootkit cannot be detected. They do not modify the kernel therefore these rootkits can be easily detected by comparing the outputs from user level utilities with the outputs obtained from the kernel.

\textbf{Kernel-level Rootkits} modify the kernel to provide faked information. To hide its presence and compromise the system, these can hook into the kernel and modify system calls, patch kernel jump tables, patch kernel code and modify critical kernel objects. These can be injected by Loadable Kernel Modules or by writing to the kernel memory via memory devices such as \emph{/dev/kmem} or \emph{/dev/mem}.

 
\subsubsection{Attack Approaches}  
These are some of the attacks performed by rootkits. 

 
\begin{itemize} %[\setlabelwidth{System call Interception} \usemathlabelsep]


\item \textbf{Process Hiding - }  
Kernel uses data structures to display the list of processes that are executing on the system. Modifications to these data structures can hide the malicious processes from being displayed.

 
\item \textbf{System call Interception - }
Kernel mode privileged instructions has the ability to access the entire address space. The activation of the Kernel Mode is done by a system call, these system calls can be intercepted by below modifications \cite{re-establishTrust}.

	\begin{itemize}
	\item \textbf{Entry Redirection - }
	Redirects individual system calls within the system call table. Modifies original system call table
	
	\item \textbf{Entry Overwrite   - } 
	Overwrites individual system call code. Does not modify original system call table
	
	\item \textbf{Table Redirection - }
	Redirects the entire system call table. Does not modify original system call table.
	
	\end{itemize}	
	 
\item \textbf{Interrupt Hooking - }
Interrupts raised in a system are handled by invoking the proper Interrupt handler based on the Interrupt Descriptor Table (IDT). Rootkits can be executed instead of the proper Interrupt Handler by modifying the entry in the IDT to execute the rootkit or modifying the first few instructions in the interrupt handler to invoke the rootkit.
 
\item \textbf{Modifying the Kernel Memory Image - }
Interfaces provided to writing to the Kernel can be used to modify the kernel to execute malicious code.

 
\end{itemize}
 

\subsection{Xen Virtualization technology}

Xen is an Open Source virtualization software based on para-virtualization technology. Para-virtualization requires the modification of the host OS, yet provides near native performance \cite{XenArtOfVirt}.

There are many benefits in choosing Xen for the study. Para-virtualization offers better performance and there is a open source version of this commercially available virtualization technology.

\begin{figure}
\caption{Xen Architecture  \label{fig:xen}}
\begin{center}
\ifpdf
    \includegraphics[width=3in]{images/xen.jpg}
\fi
\end{center}
\textsl{Xen Architecture. (extracted from 'An Introduction to Virtualization' \cite{introXen})}
\end{figure}

Figure \ref{fig:xen} shows the architecture of Xen 3.0, with 4 VMs. The architecture includes the Xen VMM a thin layer of software operating directly above the hardware. Xen VMM exposes a VM abstraction that is slightly different to the underlying physical hardware (x86). VMs executing on Xen are modified to work with the exposed architecture.

A VM running on Xen is called a domain. Dom0 is the privileged domain that always runs. has the access to the "Control Interface" of VMM through which VMs are created, destroyed and managed. Dom0 can access other VM's memory in a low level way, where the raw memory without its semantics can be accessed.


\subsubsection{Xen Memory Management}
Each VM as well as the VMM needs to be allocated with physical memory. Xen traps the ownership and use of each page, allowing secure partitioning between domains\cite{xenInterface}.

Xen has a few memory types. These support for fragmented physical address space. Below are the three levels of memory available in Xen. 

\begin{itemize}
\item \textbf{Machine Memory  - }
This the physically available whole memory. The memory is represented as 4kb Machine page frames(MPF). This is the same across Xen and any Domain. These are the addresses used by the hardware.

\item \textbf{Physical Memory - }
This provides a per domain abstraction for memory. Allows sparsely allocated memory to appear as contiguous.
This acts as the physical addresses in a normal host, a virtual machine views these addresses as the physical address.

\item \textbf{Virtual Memory  - }
This is the same as the virtual memory used in normal hosts.

\end{itemize}

The VMM as well as each VM needs to be provided memory. Xen traps the ownership and use of each memory frame, allowing secure partitioning between domains \cite{xenInterface}. Each VM is allocated the memory for its use by the VMM. The memory VMs access are the physical addresses, these memory addresses are in reality mapped to the physical memory through the VMM. A physical address from each VM has a relevant machine address.

Mapping the virtual addresses to physical addresses is done using the page tables maintained by the kernel of each VM. The mapping between machine page frames and physical page frames is done by globally readable 'machine-to-physical' tables which are maintained by the VMM. 


\section{Xen based IDS Design}

The design approach to the Xen based IDS is based on the virtual machine introspection based architecture \cite{garfinkel:vmi}. Introspection is the use of virtualization to detect state of one kernel from a within a different kernel.

The VMM acts as a trusted computing base (TCB), providing a secure base to the whole system. Xen VMM will directly run on top of the x86 hardware. Xen will act as the resource manager of the whole system, by  allocating resources and by providing access control to these resources. The main resource considered in this project is memory. Memory will be allocated to virtual machines and access of the memory will be controlled  by Xen VMM.


The Integrity monitor will be implemented as in figure \ref{fig:MonitorDesign}. The Vulnerable VM and the Monitoring VM will be running on two different VMs, with both VMs running x86\_32 bit Linux with non PAE memory addressing. Vulnerable VM will be run on a guest VM also known as a domU and integrity monitor will run on the Dom0 privileged host. Dom0 where the integrity monitor runs ( monitoring VM ) is the most crucial component of the system, as this is a point which can break the whole system making it unreliable again. Therefore the Dom0 has to be protected well against any access to it. There would be many possible ways to deny access to the Dom0 from the network. Using these techniques, dom0 will be protected thoroughly making access to it very hard.

Adopting the above mentioned architecture provides some desirable features that should exist in introspection \cite{bryanSecureVM}. There are no modifications to the VMM, no modifications to monitoring VM or the vulnerable VM. Implementation should provide the ability to monitor any data on target OS at the same time ensuring that the vulnerable VM cannot tamper with the monitors. The solution is build using XenAccess \cite{bryanSecureVM} which provides these requirements, therefore this integrity monitor will inherit those properties, but when designing the further developments have to make sure that the above features are preserved. The biggest challenge next is to provide semantics to the raw memory.

The proposed IDS is build using XenAccess \cite{bryanSecureVM} which provides these requirements, therefore this integrity monitor will inherit those properties, but when designing the further developments have to make sure that the above features are preserved.

\begin{figure}
\begin{center}
\caption{Integrity Monitor Model \label{fig:MonitorDesign}}

\ifpdf
    \includegraphics[width=3in]{images/projectDesign.png}
\else
    \includegraphics{images/projectDesign.png}
\fi
\end{center}
\end{figure}

\subsection{Xen IDS Functionality}

When a kernel object of the vulnerable host is needed to be accessed by the monitor, the initial work of mapping the memory will be done by XenAccess. XenAccess provides the requested memory location of a particular VM by mapping its relevant memory frame to the monitoring VM. XenAccess can find the starting physical address of a particular kernel memory object through the System.map file of its kernel. XenAccess finds the physical address of the virtual address by traversing the page tables of the vulnerable VM. After the physical address is known the machine address is discovered and then the memory frame including this machine memory address is mapped to the monitoring VM. This frame of raw memory is provided with an offset into the proper location. The upper layer casts the provided memory to the appropriate memory structures.

After the mapping of memory is done, the major challenge is to regenerate the semantics of the memory. In this project simple static kernel objects that are essential to integrity checking are regenerated and checked for integrity violations. As a further effort, the regeneration of the task\_list and module\_list can be done. This is much challenging as this is a dynamically changing list at runtime and the list also varies at compile time according to various configurations that are used.

The same kernel memory structures can vary even by compiling the kernel with a different configuration. Therefore a proper way of obtaining the exact kernel structures is a necessity. The structure definitions of the monitored VM will be stored and accessed by the layer generating the Kernel Objects. Another difficulty of reconstructing the semantics is the difficulty of finding the end of a particular object. The ending memory location is essential when it comes to accessing kernel functions residing in the memory.

Once the required kernel memory objects are reconstructed, the integrity monitor can work on the provided objects and do the detection of exploitations in these kernel objects. The original values of the static kernel objects will be stored so that once a exploitations occurs, these original values will help identify what has been changed and can even reverse the change to restore the previous state.

Integrity checking requires the verification of a another type of memory content, which is instruction code that are executable ( such as system calls ). For the checking of code segments exact semantic regeneration is not needed. Yet the ending location of a code has to be found for the proper integrity checking. It is also possible to check only a limited size from the start of the system call as changes to system calls are usually done at the start of the system call.

\subsection{Semantics Generation}

The link between the lower level raw memory obtained by Xen and the application level integrity monitor is the semantics generation step. The proper functioning and the reliability of the integrity monitor depends most on the semantic generation. 

The kernel is built up using various data structures and executable code. Each of the lists, tables, trees, graphs maintained by the kernel have to be handled differently according to the functionality they provide. Static kernel structures are easier to handle as they done change over time. The exact data type of a kernel object is needed when dynamic kernel structures are needed to be monitored. Dynamic kernel structures usually create a collection of objects by linking between each other. The creation of the proper links requires the exact data structure to be known. Without the exact data structure it would be impossible to obtain the references maintained to create the links between the structures.

In Dynamic kernel structures another difficulty lies in maintaining the ever changing list of kernel objects. The dynamic kernel objects constantly keep on adding nodes, deleting nodes and modifying nodes. This change should be reflected in the mapped data structures.

\subsection{Kernel access interface}
The kernel objects with the proper semantics should be easily accessible to the developers of the intrusion detection system. The kernel access interface provides a higher level view to obtain the created kernel objects.

The kernel objects that should be generated are requested by the access interface. When a object is requested, the lower level layers do the address translation, mapping of the required memory frames, discovery of the kernel objects exact data type and casts the memory into the proper data type to provide semantics and is maintained as mapped kernel objects. The integrity monitors can access the obtained data structures through this interface. This interface hides the complexity of the underlying layers from the integrity monitor.




\subsection{Critical Kernel Areas to monitor}

The success of the detector's ability to detect many exploits depends on the amount of kernel objects been monitored. There are two types of kernel objects which are static objects and dynamic objects.

\subsubsection{Static Kernel Objects}

These are the data structures maintained by the kernel which does not change during execution. These data structures are populated to the memory at the time of booting the system. It is very rarely that some of these static kernel objects are required to be changed. During the normal functioning of the kernel these data structures do not change. These static kernel objects can be monitored for any change by taking hash values of these data structures periodically and checking if the hash value is the same. If a change occurs to these static objects, the hash value is reported to be changed. Then the object can be compared with a original version of the object to find where the change has occurred. The change can then be reported so that corrective action can be taken.

Following are some of the static kernel data structures that are more vulnerable to be attacked.

\begin{itemize}
	\item \textbf{Kernel Text         - } Can be monitored to check if the kernel instructions change. The locations to obtain for kernel text is range[\_text , \_etext] and [\_sinittext , \_einittext]
	\item \textbf{System call table   - } Whenever a system call is made, the references for the system call is located in sys\_call\_table. This table is one of the most attacked places of the kernel.
	\item \textbf{Other system tables - } There are some static kernel objects that are attacked often such as Interrupt descriptor table and  page-fault handler exception table. These objects which need to be monitored usually are not available in the Xen enabled host, so it is not needed to scan those tables.
	
\end{itemize}

\subsubsection{Dynamic Kernel Objects}
These data structures change as the kernel execute. Most of these data structures form a linked list to maintain the data structure. The list as well as each node itself can change anytime, therefore it is hard to device a method to accurately detect violations on these lists. 
One method is to detect if there are hidden entries. To detect hidden entries the same information can be obtained from both a user level utility and using the kernel data structures. If there is a mismatch it is possible to say that entries have been hidden.
Another method is to have a white list of allowed entries for dynamic objects and detect for any unlisted objects.

Following are some of the dynamic kernel data structures that are vulnerable to be attacked.

\begin{itemize}
\item \textbf{Kernel module  - } show the loaded modules to the kernel. Loading a rootkit can be done by installing a kernel module. Detecting for these can find malicious modules in execution.

\item \textbf{User Process   - } this is the list of processes that are executing on the OS. Malicious application can be run as a processes. 

\item \textbf{Network Socket - } rootkits can run hidden daemons to provide remote access to outside. These unwanted network connections can be detected.

\end{itemize}



















\section{IDS Memory Address Translation}

Xen Memory Management partitions memory in three levels as machine addresses, physical addresses and virtual addresses. 
Memory Management in Xen is done at page frame level, where each physical memory frame is mapped to a machine memory frame. This mapping is stored in a globally readable 'machine-to-physical' table.
Usually memory space allocated for a VM is independent from each other VM. Through the mapping of memory for introspection we make the memory locations accessible from the monitoring VM as well.
The memory address translation is done in two different ways for linear mapped addresses and non-linear mapped addresses. Here we will only look at x86\_32 bit architecture with non-PAE memory addressing. 
The address space can address 4Gbs of memory. The first 3 Gbs for user-mode applications and the last 1Gb for kernel mode addressing. Figure \ref{fig:memoryTranslate} contains a diagram showing two kinds of kernel addresses and the relationship to physical addresses.

\subsubsection{Linearly mapped memory}
Linux kernel reserves the virtual addresses above 0xc0000000 for kernel text and data structures \cite{understandLinuxKernel}. Virtual Addresses between 0xc0000000 and the point marked \emph{high memory} in the diagram are linearly mapped addresses. Linux kernel maps the linear-mapped addresses in a linear way to the physical addresses, and here the physical addresses can always be found by subtracting the constant 0xc0000000 from the linear-mapped address. This linear mapping is showed by the arrow A in the figure. 

\subsubsection{Non-Linearly mapped memory}
The dynamically allocated kernel data structures reside in the region of the region from \emph{high memory} to \emph{0xfe000000} as in Figure \ref{fig:memoryTranslate}. Page tables are used to translate the virtual addresses of this region to physical addresses. 

\subsubsection{User-mode addresses}
The addresses used by the user level applications are also non-linearly mapped. The address translation of virtual to physical addresses in this region are also done using page tables maintained by the kernel. In order to access these page tables residing on another VM, the memory areas where the page tables as well as the referencing page tables will have to be mapped. 
 

\begin{figure}
\begin{center}
\caption{Kernel level Virtual Address Translation \label{fig:memoryTranslate}}

\ifpdf
    \includegraphics[width=3in]{images/memoryTranslate.png}
\fi
\end{center}
\begin{center}
{Extracted from \cite{copilot} and reproduced}
\end{center}

\end{figure}

\subsubsection*{Address Translation walkthrough}

The source code of XenAccess was studied to learn how the mapping of memory takes place, the procedure is as follows.

\begin{enumerate}

\item \textbf{Initializing domain information } \newline A interface into the Xen Control is opened and used to populate the domain information of the vulnerable VM. Init PAGE OFFSET values.

\item \textbf{Find the Page Global Directory  } \newline
Read the System.map file of the kernel and find the virtual address of \emph{swapper\_pg\_dir} entry. Page Global Directory starts at symbol \emph{swapper\_pg\_dir}. Translate this virtual address to the physical address by reducing the PAGE OFFSET ( 0xc0000000 ).

\item \textbf{Map the Physical address frame of GPD  } \newline
Partition the physical address of the PGD pointer into physical frame number and offset. Convert the physical frame number to machine frame number using \emph{physical to machine} table. Map the corresponding machine frame into the monitoring VM's memory space. The exact reference can be accessed using the earlier offset value.

\item \textbf{Memory Translation using page tables  } \newline
Only the GPD table's reference is maintained initially. When a address needs to be translated, the translation starts in the Global Page then page tables are traversed to obtain the physical address.

\item \textbf{Physical address to Machine Address Translation } \newline
The obtained physical address is broken down into the physical frame number and an offset. Using the p2m ( physical to machine ) table in the VMM the Machine frame number of the Physical Frame number can be found.

\item \textbf{Map the memory location } \newline
 When the needed memory location is translated into machine or physical address, XenControl library is used to map the memory frame into the monitoring VM's memory space. The exact memory location can be accessed by using the offset.


\end{enumerate}



















\section{Implementation}

The solution is implemented on a Ubuntu 7.10 Gutsy Gibbon Linux System. The hypervisor used is 3.1 Xen hypervisor for i386 architecture with non PAE. XenAccess version 0.4 was used for the implementation.
The Dom0 uses 2.6.20-100-generic kernel provided by Cedric Schieli. The vulnerable DomU uses a 2.6.18-xenU kernel compiled locally to support 32bit non-pae hypervisor.

When deploying a Xen system, one must be sure to secure the management domain(Dom0) as much as possible. If the management domain is compromised, all other domains are also vulnerable. A set of best practices are used to secure Domain-0 \cite{xenUser}. 

This project is built on top of XenAccess which is an open source library to help the mapping of virtualized memory between virtual hosts. The main functionality provided by XenAccess is the translation of memory addresses needed to map the memory. After the required address is found, the mapping of that address to another host is provided by Xen control library (XenCtrl). Translation of addresses on Xen virtualization is the initial step in implementing inter-VM memory accessing systems.

\subsection{Implementation of the Integrity Monitor}

The integrity monitor is implemented as a user level application running on the DomU and it uses the library XenAccess to perform a major task of providing the memory needed. The programming language used to implement the integrity monitor is C. It has use C because the main library which is XenAccess is written in C and the low level memory accessing and usage of pointers can be done using C.

The current implementation has the ability to support the integrity checking of any static kernel table. Yet only the system call table is checked in the current version of the implementation. The single most successful location to monitor most number of kernel exploits is the system call table. The authors of the copilot paper \cite{copilot} have correctly detected the presence of 12 real-world rootkits by scanning the system call table. Many of the exploits can be easily done by redirecting the system call pointers. The prototype implementation of this project also is implemented to detect any change been done to the system call table.

The location of \emph{sys\_call\_table} symbol on the vulnerable host is found using the \emph{System.map} file corresponding to its kernel. XenAccess helps to map the memory of the vulnerable VM to the Monitoring VM and provides a void pointer to it. Next the implementation periodically checks the hashes for the kernel tables. If a change in hash occurs, the locations of the change are found by comparing the current kernel table with the original table. The changed positions are reported.



\subsubsection*{Semantics Generation}

In the current implementation the semantics are provided by manually inspecting the source code of the kernel table and when coding, statically provide the data type. Examining the source code of the system call table leads to the structure of the table. The system call table in memory would look like a array of function pointers of data type \emph{long}.



\subsection{RootKit Implementation}

The amount of rootkits that are available for the 2.6 kernel are very low or not publicly available. In the article \cite{norootkits} it has been mentioned about the  lack of rootkits. In that article itself they describe how to implement a rootkit which shows that rootkits are possible to be deployed on 2.6 linux kernels.

Due to the lack of publicly available rootkits that run on the DomU ( 2.6.18 kernel), this project implements a small loadable kernel module that changes entries of the \emph{sys\_call\_table}.





\section{Evaluation}

\subsection{Testing the Integrity monitor functionality}

The success of this project is based on the ability to correctly monitor a change of the vulnerable VM from the monitoring VM.
Obtaining the needed kernel object for monitoring is done through a series of steps and each of these steps have the ability to misbehave and silently map a different memory location, leading to false detection.

Testing of the implementation can be done by checking if a change to system call table in the vulnerable VM is correctly detected by the detector running on detecting VM. To do testing the rootkit is made to periodically change and restore the system call table from index 0 till 300. The periodic changes should be correctly identified by the integrity detector.
When the prototype rootkit runs the change occurring in each system call entry is successfully detected by the integrity monitor. This verifies that the mapping of memory has happened accurately and that the changes are been reported accurately.


\subsection{Performance Evaluation}

The integrity monitor constantly keeps on generating hashes and comparing it with existing hash to check if a change occurs. This action is done every two seconds, and could cause a considerable performance degration to the system. In order to measure the performance penalty a classical benchmark is used. The benchmark is the time taken to decompress the linux-2.6.18 linux kernel. The benchmark used the average time outputs of unix command \emph{time} been run for 10 times to decompress the kernel source.

The test was run on a normal VM, on the Dom0 when the integrity detector is not executing and on the Dom0 when the integrity detector is running. Table \ref{table:time} shows the time values obtained for each situation.

\begin{table}
\caption{Average time for kernel source archive decompression}

\begin{center}
    \begin{tabular}{ | l | l | l | l |}	
    \hline
    		&  		Normal		& 	\multicolumn{2} {|c|}{Xen Virtualized}	\\    \hline 
      		& 	Normal Host 	&	Dom0 with detection & Dom0 without detection \\ \hline \hline
    real	& 		24.93s		&		31.48s			&		31.48s			\\ \hline	
    user	& 		18.97s		&		18.40s			&		18.42s			\\ \hline	
    sys		& 		03.09s		&		08.83s			&		10.01s			\\ \hline	
    
    \end{tabular}
    \label{table:time}
\end{center}
\end{table}

Under virtualized host time detection, there exists a vulnerable VM both when the detector is running and not running.

When considering between the Virtualized system with detector running and without the detector, the table does not show any significant difference in real time and user time. But when the detector is running, the system shows a speedup in system time. This might be due to the fact that Dom0 has a GUI with which the user interacts but the GUI of the vulnerable VM has no user interactions.

What we see here is that there is no significant performance degration when the integrity monitor keeps on checking for hash changes every two seconds.
 

 
\section{Related Work}

The idea of this project was inspired by the many others who have researched and implemented secure systems using virtualization.

The initial idea for introspection based security systems using virtualization technology was published by Garfinkel \cite{garfinkel:vmi}. This paper initiated a new field of research that could bring more secure systems implementations. The system was implemented on a modified VM ware workstation and had the ability to intercept the VMs system call requests. They achieved many detection methods for successful detection where some of the detection approaches are enabled by the modifications to VMM and guest host.  
Changing any code for the purpose of the detection system is something that is tried to be avoided in this implementation. Only the existing support of XenControl library is used and the rest of the detector resides on a user level application.


XenFit \cite{XenFIT} is a file-system integrity monitor running on Xen. XenFIT can monitor and fires alarms on intrusion in real-time manner. XenFIT works by dynamically patching memory of the protected machine, so it is not necessary to install any kernel code or user-space application into the protected machines. XenFit checks for file system security breaches by detecting integrity violations from a clean VM.

The paper \cite{re-establishTrust} handle the problem of trusted system calls been replaced with trojaned system calls. Their approach to recover from these type of rootkits is to extract the system call table from a known-good kernel image and reinstall the system call table into the running kernel. They discuss future generation rootkits and address how to recover from them.
In our project implementation the original kernel table is maintained allowing the ability to replace the system call table entry to the original value in case of a change.

Copilot is a kernel integrity monitor that is run on a PCI add-in card \cite{copilot}. The copilot detector does not run on the infected kernel, making reliable detection possible. Copilot monitor can be expected to correctly detect malicious kernel modifications even on hosts with kernels too thoroughly compromised to allow the correct execution of traditional integrity monitoring software. The Copilot monitor does not require any modifications to the host’s software and can therefore be easily applied to commodity systems. The Copilot monitor prototype has proven to be an effective kernel integrity monitor in tests against 12 common kernel-modifying rootkits. 


VMwatcher \cite{vmIntroSemantics} is a system where existing anti malware systems are made to scan the monitored host from ``out of the box". Their main issue address is the bridging of the semantic gap that exists between two virtual machines. They have run several existing antivirus software and successfully scanned for vulnerabilities on a few virtualization technologies. The existing anti virus scanning is done using file system semantic regeneration which is considered to be easier than memory semantic regeneration. The memory semantic regeneration they have used is similar to the approach we have made in this project. The exact method in which they obtain the differing kernel objects or data types has not been clearly mentioned. The source code of their implementation is also not available therefore using their approaches or studying how they have implemented is not possible.


XenKimono \cite{rootkit} is a implementation of a tamper resistant rootkit detector using Xen. The rootkit detector runs on a different VM than the VM being monitored. XenKimono is a extensive rootkit detector that scans many different areas of the kernel at runtime. It detects for changes to static kernel objects. Uses cross view detection methods to find differences between user level view and kernel level view of kernel modules, user processes and network sockets. Watch for user privilege changes and looks at the network interface. It has successfully detected few rootkits and can detect unknown rootkits if the new rootkit employs at least one of the detection methods used.
XenKimono has not described how it does the address translations needed before the mapping of memory. The way in which they have obtained the semantics seems to be a good way, but its implementation or logic is not described. The DomU kernel they use have to be compiled with kernel debugging information which means that XenKimono will not work for any compilation configuration. XenKimono has still not been published using GNU license as a open source project so there is no way to learn from their implementation.

XenAccess open source library \cite{bryanSecureVM} was the main base used in this project to facilitate introspection. XenAccess library focuses of using the features in Xen to facilitate introspection without modifying the Xen hypervisor. This library allows the privileged domain to access another domain's memory addresses directly. Even though the library can be used straight forward to get memory mapped there is a lot of functionality with respect to Xen virtualized memory management being done internally. A small portion of kernel memory can be mapped linearly. Yet translation of a very large portion of memory space should be done through the use of page tables. This complexity has been handled by the library to provide introspection based intergrity detectors look into other complexities.
XenAccess has a few limitations where only a few Xen versions are supported as it is still in its development.
The internals of how address translations happen is a main function that has to be learned when doing memory introspection. Therefore XenAccess source code was read to get a understanding about address translation internals.


All of the above mentioned projects as well as few more related projects helped in the completion of this project. Most of the projects were used to get the higher level ideas whereas XenAccess provided the implementation level understanding of how introspection happens. 



\section{General Discussion}

This project looked at how memory introspection can be done, the internals of memory address translation, mapping the memory and implemented a prototype integrity monitor to detect changes to the static kernel objects specifically the system call table in the current version of the prototype.

There are changes in a xen kernel that is different from a normal kernel. For example the Interrupt descriptor table is not available in virtualized host running on Xen. So it is not possible to detect the integrity of the static kernel table IDT. The integrity monitor design should identify these changes in the Xen enabled kernels.

Mapping of memory is done in individual memory frames at a time. If a kernel object spans across multiple frames, additional work have to be done to align the raw memory as contiguous memory. This was found to be a additional thing that should be looked into when mapping memory regions.

The process list generation was attempted but finding the precise task\_list struct of the vulnerable VM was not a easy task to do. Without the precise data type of the structs are essential to build up the linked list that describe the processes running on the system. Considering task\_list struct the difficulty is not being able to determine the struct using the source code as it describes different internal data structures for task\_list for different kernel compilation configurations. This is the same difficulty faced when recreating the semantics of any kernel object.

Rootkits that can be run on the system were needed for the testing for the success of the integrity detector. There were no publicly available rootkits that run on 2.6 kernels other than the adore-ng-0.41 rootkit. Even adore rootkit did not compile on the 2.6.18 and 2.6.22 kernels. Modifying the available rootkits to run on a 2.6 kernel would have needed an extensive study into the rootkits. This caused the testing using a real rootkit impossible.

In real life situations even though it is hard to compromise a VMM, there are methods in which the VMM can be compromised. Attacks on Virtual Machine Emulators paper \cite{VMattacks} describes the types of attacks available to VMMs. Even though the attacks available for Xen is low, there is always some possibility of Xen been attacked. The possibility to avoid a attack on the VMM can be achieved by securing the Dom0 as much as possible.


\section{Future Works}

Next versions of this integrity monitor will require the integrity checking of other static kernel objects, the integrity checking of system calls and static kernel code.

When a change in kernel tables occur, the changed value can be restored to the original values. At the moment the memory is mapped in a read-only manner, but to restore kernel table entry values the memory will have to be mapped with write enabled. The impact this can have should be analyzed. Most probably there won’t be an issue as writing is only enabled by the Dom0 and its maintained in a secure manner.

Implementation of a successful integrity detector on Xen would require the ability to Map kernel objects and instruction code that span for multiple memory frames. Memory for the VMs don't see a contiguous abstraction of memory as the hypervisor handles that complexity and provides a contiguous looking physical memory for the VMs. A approach that can hide the non-contiguous nature of virtualized memory and provide a contiguous abstraction should be implemented.

The next most important future work is to extract the data types using a kernel image and providing those data types to the integrity monitor to re-create objects. The most successful semantic generation that can be achieved is when at runtime be able to handle different kernels with changing data types. The integrity monitor should be compiled independent of the kernel being monitored but when detecting a VM, be able to extract the semantics of that kernel and map those objects correctly to the running integrity monitor.

%Intergrity monitoring for the windows kernels that can run on Xen is also a work to be looked into.


\section{Conclusion}

The inability of commodity operating systems to isolate different parts of the kernel leads to the entire kernel getting compromised. Virtualization is the solution to the problem.

Using Xen it is possible to isolate the vulnerable kernel and the detection kernel making detection reliable. The memory mapping functionality of Xen provides the ability to look into the memory state of the vulnerable VM. 


There are many issues to address before a successful intrusion detection can be built. First the address of the needed kernel objects need to be translated, and then the required memory frames should be mapped and given a abstraction to be accessed as a contiguous block of memory. When the raw memory is obtained, the semantics of the kernel objects should be found and then the memory should be cast into the obtained data types. When the kernel objects are constructed there should be a way to dynamically change the created dynamic kernel object lists in real time. After the underlying objects mimic the behavior of the vulnerable VM, there should be a developer friendly interface to access these kernel objects. Finally the intrusion detection logic can be implemented to do the necessary detection. The detection can monitor various parts of the kernel to detect for the proper functioning of the vulnerable VM. In case of a compromise the necessary action can be taken to correct the trusted operation again.

In this project the above mentioned steps were found to be needed when creating a intrusion detection system using virtualization. The prototype integrity monitor implemented in this project can successfully detect changes to the system call table in a real time manner and not affecting the performance of the system. The future versions of the prototype will include additional functionality described under future works.











% An example of a floating figure using the graphicx package.
% Note that \label must occur AFTER (or within) \caption.
% For figures, \caption should occur after the \includegraphics.
% Note that IEEEtran v1.7 and later has special internal code that
% is designed to preserve the operation of \label within \caption
% even when the captionsoff option is in effect. However, because
% of issues like this, it may be the safest practice to put all your
% \label just after \caption rather than within \caption{}.
%
% Reminder: the "draftcls" or "draftclsnofoot", not "draft", class
% option should be used if it is desired that the figures are to be
% displayed while in draft mode.
%
%\begin{figure}[!t]
%\centering
%\includegraphics[width=2.5in]{myfigure}
% where an .eps filename suffix will be assumed under latex, 
% and a .pdf suffix will be assumed for pdflatex; or what has been declared
% via \DeclareGraphicsExtensions.
%\caption{Simulation Results}
%\label{fig_sim}
%\end{figure}

% Note that IEEE typically puts floats only at the top, even when this
% results in a large percentage of a column being occupied by floats.


% An example of a double column floating figure using two subfigures.
% (The subfig.sty package must be loaded for this to work.)
% The subfigure \label commands are set within each subfloat command, the
% \label for the overall figure must come after \caption.
% \hfil must be used as a separator to get equal spacing.
% The subfigure.sty package works much the same way, except \subfigure is
% used instead of \subfloat.
%
%\begin{figure*}[!t]
%\centerline{\subfloat[Case I]\includegraphics[width=2.5in]{subfigcase1}%
%\label{fig_first_case}}
%\hfil
%\subfloat[Case II]{\includegraphics[width=2.5in]{subfigcase2}%
%\label{fig_second_case}}}
%\caption{Simulation results}
%\label{fig_sim}
%\end{figure*}
%
% Note that often IEEE papers with subfigures do not employ subfigure
% captions (using the optional argument to \subfloat), but instead will
% reference/describe all of them (a), (b), etc., within the main caption.


% An example of a floating table. Note that, for IEEE style tables, the 
% \caption command should come BEFORE the table. Table text will default to
% \footnotesize as IEEE normally uses this smaller font for tables.
% The \label must come after \caption as always.
%
%\begin{table}[!t]
%% increase table row spacing, adjust to taste
%\renewcommand{\arraystretch}{1.3}
% if using array.sty, it might be a good idea to tweak the value of
% \extrarowheight as needed to properly center the text within the cells
%\caption{An Example of a Table}
%\label{table_example}
%\centering
%% Some packages, such as MDW tools, offer better commands for making tables
%% than the plain LaTeX2e tabular which is used here.
%\begin{tabular}{|c||c|}
%\hline
%One & Two\\
%\hline
%Three & Four\\
%\hline
%\end{tabular}
%\end{table}


% Note that IEEE does not put floats in the very first column - or typically
% anywhere on the first page for that matter. Also, in-text middle ("here")
% positioning is not used. Most IEEE journals/conferences use top floats
% exclusively. Note that, LaTeX2e, unlike IEEE journals/conferences, places
% footnotes above bottom floats. This can be corrected via the \fnbelowfloat
% command of the stfloats package.






% conference papers do not normally have an appendix


% use section* for acknowledgement
%\section*{Acknowledgment}


%The authors would like to thank...





% trigger a \newpage just before the given reference
% number - used to balance the columns on the last page
% adjust value as needed - may need to be readjusted if
% the document is modified later
%\IEEEtriggeratref{8}
% The "triggered" command can be changed if desired:
%\IEEEtriggercmd{\enlargethispage{-5in}}

% references section

% can use a bibliography generated by BibTeX as a .bbl file
% BibTeX documentation can be easily obtained at:
% http://www.ctan.org/tex-archive/biblio/bibtex/contrib/doc/
% The IEEEtran BibTeX style support page is at:
% http://www.michaelshell.org/tex/ieeetran/bibtex/
%\bibliographystyle{IEEEtran}
% argument is your BibTeX string definitions and bibliography database(s)
%\bibliography{IEEEabrv,../bib/paper}
%
% <OR> manually copy in the resultant .bbl file
% set second argument of \begin to the number of references
% (used to reserve space for the reference number labels box)

\bibliographystyle{IEEEtran}
\bibliography{IEEEabrv,papers}



% that's all folks
\end{document}


